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REMARKS 

Applicants submit the present Amendment in response to the Office Action of November 
4, 2005 ("Office Action"). Applicants appreciate the indication that Claims 3, 4 and 7 are 
directed to subject matter that is patentable over the cited art. Applicants have rewritten Claim 3 
into independent form, and changed the dependency of Claim 4, thereby placing Claims 3, 4 and 
7 in condition for allowance. Applicants have also added three new claims (Claims 23-25), and 
made a minor amendment to Claim 7. 

As discussed below, Applicants believe that the combination of cited references do not 
disclose or suggest all of the recitations of the pending rejected claims, nor do Applicants believe 
that a person of skill in the art would have been motivated to combine the references in the 
manner stated in the rejections. Accordingly, Applicants respectfully submit, for at least the 
reasons explained below, that the pending claims are now all in condition for allowance, which is 
respectfully requested. 

I. The Rejections Under 35 U.S.C. § 112 

Claims 3 and 4 stand rejected under 35 U.S.C. § 1 12, f 2 as being indefinite because "the 
claimed LUSTAT message is not defined by the specification." (Office Action at 2). Applicants 
call the Examiner's attention to the sentence spanning pages 16-17 of the specification, which 
notes that a "LUSTAT message refers to a command flow which requests that the SNA 
application resent or 'refresh* the last screen which the TN3270E client 60 acknowledged as 
having received correctly." Thus, as the term "LUSTAT" is in fact defined in the specification, 
Applicants respectfully submit that the above-recited rejection of Claims 3 and 4 under Section 
112 should be withdrawn. 

Claim 4 also stands rejected under 35 U.S.C. § 1 12, % 2 as being indefinite because there 
is no mention of an LUSTAT message being sent. (Office Action at 2). Consistent with the 
Examiner's recommendation, Applicants have amended Claim 4 to depend from Claim 3, 
obviating this rejection. 
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II. The Rejections Under 35 U.S.C. § 103 

A. The Rejections of Claims 1-2, 5-6, 8, 19 and 21 

Claims 1, 2, 5, 8, 19 and 21 stand rejected under 35 U.S.C. § 103 as obvious over U.S. 
Patent No. 6,415,331 to Ariga ("Ariga") in view of IBM TDB-ACC-No. NNRD4221 15 ("the 
IBM '115 reference"). (Office Action at 3). Claim 6 stands rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Ariga in view of the IBM f l 15 reference and further in view of U.S. 
Patent No. 6,006,331 to Chu et al. ("Chu"). The Office Action states, among other things, that 
Ariga discloses reestablishing the IP connection between a server and a client and further teaches 
forwarding a refresh request to a host application. (Office Action at 3, 8(a)). The Office 
Action concedes that Ariga does not teach (1) that the host application is an SNA application or 
(2) that the request sent to the host application is a screen refresh request. (Office Action at 3, 1) 
8(a)). The Office Action states, however, that the IBM '115 reference discloses an SNA host and 
sending files from a TN3270 server to a TN3270 client, and that it would have been obvious to 
combine Ariga and the IBM '115 reference to arrive at the invention of Claims 1, 2, 5, 8, 19 and 
21. (Office Action at 3-4, f 8(a)). Applicants respectfully traverse these rejections. 

As an initial matter, Ariga does not disclose "forwarding a screen refresh request" to an 

application server. In particular, the term "screen refresh request" is defined in the present 

application as follows: 

A screen refresh request constitutes a request that the application retransmit the 
data required to redisplay a screen that was previously displayed on the client 
terminal . So long as the SNA application includes such a screen refresh capability, it 
may retransmit to the TN3270E client the data corresponding to the last screen . . . which 
was confirmed as having been received by the TN3270E client. 

(Application at page 13, line 31 through page 14, line 7) (emphasis added). Thus, "forwarding a 
screen refresh request" as recited in Claim 1 refers to a request that the SNA application resend 
a previously sent data screen . In contrast to the method of Claim 1, the cited portions of Ariga 
involve sending new data that has not been previously sent. Specifically, Ariga teaches that if, 
after a disconnected link has been reconnected, it is determined that the data that was being 
forwarded when the disconnection occurred had not been subsequently updated, then the 
gateway server merely resends the information to the client (as the gateway server buffers the 
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information it sends). (See Ariga at Col. 7, lines 56-65 and Fig. 6, items S410, S417 and S407). 
Thus, in this situation, it is clear that a "screen refresh request 1 ' is not forwarded to the 
application server, as the only flow is between the gateway server and the client. If, on the other 
hand, it is determined that the data that was being forwarded when the disconnection occurred 
has been subsequently updated, then the gateway server sends an "updated data transmission 
request" to the application server. (See Ariga at Col. 8, lines 5-26 and Fig. 5, item 307 and Fig. 
6, item S412). In response, the application server forwards new, updated data to the gateway 
server, and it is this new, updated data that is forwarded to the client . (Ariga at Fig. 6, item 
S413-S416 and S407). Accordingly, the rejection of Claim 1 should be withdrawn at least 
because Ariga does not disclose or suggest forwarding a "screen refresh request" to an 
application server. 

Applicants also respectfully submit that there is no motivation to combine Ariga and the 
IBM '115 reference in the manner suggested in the pending rejections. Ariga is directed to, 
among other things, methods that "can be used to always transmit the latest data to the client 
even when data has been updated in the application server." (Argia at Col. 5, lines 62-65). 
Pursuant to these methods, an "application server, in response to [a request for data], starts 
transmitting data specified by the data request packet to a gateway server." (Ariga at Col. 6, 
lines 65-67). The "gateway server . . . provide[s] [the] data in the form of a packet . . . which is 
transmitted to [the] radio client. (Ariga at Col. 7, lines 9-14). After radio communication 
between the client and the gateway server is lost, the "radio client transmits [a] reconnection 
request to [the] gateway server." (Ariga at Col. 7, lines 24-37). As the gateway server buffers 
information that is sent to the client but not acknowledged, upon reconnection, the gateway 
server can simply resend such data to the client. (Ariga at Col. 7, lines 56-65), The gateway 
server, however, also keeps track as to whether the information that was previously sent to - but 
not received at - the client has been updated by the application server. If it has, the gateway 
server requests and receives the new, updated information from the application server so as to 
provide the client with the latest information after the link is reconnected. (Ariga at Col. 7, lines 
37-54). 
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Applicants respectfully submit that it makes no sense to try to combine Ariga and the 
IBM '115 reference to arrive at the method of Claim 1. Ariga is directed to, among other things, 
systems and methods for providing a client the latest information. Accordingly, if the 
application server has updated the information that was requested, but not received, by the client, 
Ariga teaches that the updated information, as opposed to a screen refresh request as recited in 
Claim 1 , should be sent to the client. If the information has not been updated, there is no reason 
in the system of Ariga to contact the application server at all, as the gateway server buffers the 
information that is sent to the client and, thus, the gateway server may resend any information 
that was not received by the client without interacting with the application server. Accordingly, 
for at least each of the above reasons, Applicants respectfully submit that the rejection of Claim 
1 should be withdrawn. 

Claims 19 and 21 comprise system and computer program product counterparts to the 
method of Claim 1 . Accordingly, the rejections of these claims should be withdrawn for the 
same reasons that the rejection of Claim 1 should be withdrawn. Claims 2, 5-6 and 8 each 
depend from Claim 1, and hence the rejections of these claims should also be withdrawn for at 
least the reasons that the rejection of Claim 1 should be withdrawn. In addition, the rejection of 
Claim 5 should also be withdrawn at least for the additional reason that Ariga does not teach that 
"the screen refresh received from the SNA application and forwarded to the TN3270E client 
comprises a last data screen that was forwarded from the SNA application and acknowledged as 
received by the TN3270E client." Instead, what the cited portion of Ariga states is that newly 
updated information is sent from the application server to the client, as opposed to a data screen 
that had previously been forwarded to the client. (See Ariga at Col. 11, lines 1-11). 
Accordingly, the rejection of Claim 5 should also be withdrawn for at least this additional 
reason. 

III. Conclusion 

Applicants again wish to thank the Examiner for the thorough examination of the 
application. Applicants believe that the claims are all in condition for allowance, which is 
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respectfully requested. Should the Examiner have any questions, please feel free to call 
Applicants representative at (919) 854-1422. 

Respectfully submitted, 




D. Randal Ayers 
Registration No. 40,493 
Attorney for Applicants 
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